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@ Local communication bus system and apparatuses for use In such a system. 

@ A number of domestic audio/video apparatuses (10,12.14) are Interconnected by a Domestic Digital 
Bus (16) for the exchange of control information. A User I/O subdevice (41) in one apparatus is 
addressable by a control subdevice (22) of another apparatus to allow the display of menu items defined 
by the control subdevice (see Figure 2). The User I/O subdevice returns user control signals by reference 
to the defined menu Herns. The right of menu control can be transfemed via the User I/O subdevice to 
and from other control subdevices (20 etc.) to allow integration of the menu control functions of the 
different apparatuses. 
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The invention relates to a local communication bus system comprising first and second apparatuses con- 
nected for the exchange of messages to a serial data channel, and to apparatuses for use in such a system. 
The invention relates in particular, but rwt exdustvely, to a system of domestic audio and video apparatuses 
interconnected by a serial data channel bus for the exchange of control messages. 

5 A known serial data channel of this type is provided by the Domestic Digital Bus (D2B). standardised by 

the International Hectotechnical Commission (lEC), Geneva. The name D2B is a trademark of Philips Elec- 
tronics NV. Examples of apparatuses including D2B interfaces are PhOips' model 2070 television receiver and 
model VR6590 video cassette recorder (VCR) previously avaDable in Europe. Such a data channel has many 
applications, and it is desired that a standardised set of 'application protocols' be developed, in addition to the 

10 basic communication protocols defined by the lEC, and that these protocols should be adhered to by many 
manufacturers of consumer apparatus. In particular, the use of such protocols can bring enhanced functionality 
and ease of use to the great variety of consumer electronic apparatuses avaflable today and in the future, with 

true inter-brand compatibflity. 

The known apparatuses, for example, provide for integrated on-saeen display facilities, so that a user con- 

15 trolling the VCR can receive Information about the progress of VCR operations via the television saeen. Such 
a feature is described in more detail in our copending European patent application EP-0 505 00S-A2 
(PHQ91010), not published at the priority date of the present application. There is a desire to integrate further 
the operation of the apparatuses of the system, for example to allow the user to have dialogue with an appa- 
ratus which itself has inadequate user input/output facilities. One example would be to provide menu driven 

20 control of an apparatus which Itself has no means for displaying a n»nu, and/or no means for relating a dis- 
played menu to input received from the user. Whfle this is dearly possible in theory, there is an overriding 
cost requirement to mininnise the amount of information that one apparatus must 'know* about the other ap- 
paratuses of the system. Furthermore, it is desirable for the user dialogue functions to integrate alt apparatuses 
of the system, rather than being restricted to the control of only one apparatus in a given session. 

25 A prior system for remote menu display has been proposed in the 'Specif icatton of the interface between 
a Conditional Access Sub-System implemented as an Integrated drcuit card and a MAC-receiver*. released 
by Norwegian Telecom in July 1990. While this proposal allows the IC card ("Smart card^ to display a menu 
and receive a user selecUon. this depends strictly on the avaflability of specific marked keys on the receiver 
handset The smart card is furthermore required to receive informatton of all user control signals (for example 

30 Vdume up*), whether or not they relate to its own user dialogue. There is also no fadlity to integrate the user 
interface of many apertures of the system. 

Software interfaces for user dialogue within a single computer-controlled apparatus are also known, for 
example in the Apple Macintosh Computer, and the Gem User Interface Toolkit for Atari computers. 

It is an object of the Invention to enable the provision of improved user dialogue features in a system of 

35 interconnected apparatuses. 

The Invention provides a local communication system comprising firetand second apparatuses connected 
for the exchange of messages to a serial data channel, the system induding control means within the first ap- 
paratus and user interface means within the second apparatus, said control means including: 

means (a) for Initiating a user dialogue session with the second apparatus; means (b) for during said 

40 user dialogue session sending to the second apparatus at least one user Information item for presentation to 
a user of the system; means (c) for during said user dialogue session recehdng from the second apparatus 
Information which conveys user control signals by reference to said user Information ltem(s); and means (d) 
for controlling at least part of the system In accordance with user's wishes Inferred from the said Informatton, 
said user interface means Induding: 

45 means (e) for during said user dialogue session receiving firom the first apparatus user lnformatk)n time 

and presenting them to the user means (f) for during the user dialogue session receh^lng a control signal from 
the user, means (g) for Identifying an association between the user control signal and one of said user Infor- 
mation Items; and means (h) for sending to the first apparatus Information which conveys the reoeWed user 
control signals by reference to the assodated user Information Item, 

50 wherein the system further hdudes a third apparatus Induding further control means, said further control 
nteans Induding means corresponding at least to means (b), (c) and (d) above, wherein the control means 
within the first apparatus further Indudes means (|) ^or during the user dialogue session Initiating a transfer 
of control of said session to the third apparatus, and wherein said further control means within the third ap- 
paratus further Indudes means (k) for receiving transferred control of the user dialogue session, such that the 

55 means corresponding to means (b), (c) and (d) will continue the transferred session without acth^e partldpation 
by the control means within the first apparatus. 

By providing a transfer of control of the user dialogue session between apparatuses, the system allows 
integration of user dialogue functions over the system as a whole. If the manner of establishing the user dia- 
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logue session is standardised, this holds true even though the different apparatuses nnay come from different 
manufacturers. At the same time, the designers of new apparatuses for use in such a system will be constrained 
as little as possible by the existing features when developing new user dialogue features. 

In one embodiment, where the user dialogue session provides specifically for menu control, the user in- 
formation items include items in a menu for control of the first apparatus, and the means (g) includes means 
for identifying an association between a user control signal and a specific one of said menu items. 

The division of the menu control function in this manner between apparatuses allows the first apparatus 
to define the information content of the menu (by means of text strings or icons, for example) without regard 
for the style of menu presentation by the second apparatus (which might even speak the menu information to 
the user down a telephone line). The manner and style of selecUon of menu items is also unknown to the first 
apparatus: items might be selected by number, colour or by a movable pointer on screen. This allows maximum 
design Independence for the manufacturers of both apparatuses. 

In an example application, a VCR (first apparatus) may initiate a user dialogue session, using the on- 
screen display facilities and remote control handset of a TV set (second apparatus). If t he user selects to record 
from a channel which is scrambled (encrypted) the VCR can automatically decide to transfer the user dialogue 
session to a conditional access sub-system (third apparatus), in order that the user can obtain the necessary 
entitlement to descramble the signals for recording by the VCR. Of course the invention is not limited to a sys- 
tem of three apparatuses, or to any fixed configuration. The third apparatus may in turn transfer the user di- 
alogue session to a fourth apparatus, and so on. Thus an integrated sequence of user dialogue operations 
20 can be provided spanning the functions of several apparatuses, to implement the user's wishes in a user- 
friendly manner, with each control means deciding freely which apparatus is in the best position to implement 
the user's wishes at each stage of operation. 

The means (a) of the first apparatus may include means for storing data identifying the second apparahjs 
for the duration of the user dialogue session, while the user interface means within the second apparatus in- 
25 dudes means for storing data identifying the apparatus with which it currently has a user dialogue session. 
In a D2B embodiment, for example, the device-subdevice address of the control means may be stored. Each 
apparatus can in this way limit the number of sessions in which it can become involved, and avoid interference 
from other apparatuses connected to the bus. 

The second apparatus in such an embodiment may act as intermediary between the first and third appa- 
ratuses in the transfer of the user dialogue session. This ensures that each apparatus need communicate only 
with one other in the course of its user dialogue session, no matter how many apparatuses are involved in the 
process as a whole. Thus small and finite data storage facBities are sufficient for each apparatus, which is im- 
portant for the designer of mass-market consumer apparatuses. 

The further control means within the third apparatus may for example include means for storing data iden- 
33 tif ying the first and second apparatuses during the continuation of the user dialogue session by the third ap- 
paratus. There is thus no need for the second apparatus to remember the identity of more than one other ap- 
paratus, at least with regard to the user dialogue function. 

At the same time, each of the third and subsequent apparatuses is responail^e for remembering the ap- 
paratus which transferred the user dialogue sesston to It. and therefore can further Include means for Initiating 
40 the return of the user dialogue session to that apparatus. 

The Invention further provides an apparatus having the technical features cf the first, second and/or third 
apparatus of a system according to the invention as set forth above. Further aspects and features of the In- 
ventton will be apparent from the following description. 

Embodiments of the InvenUon will now be desalbed, by way of example, with reference to the accompa- 

45 nying drawings, in which: 

Figure 1 shows a system constructed in accordance with the Invention, and 
Figures 2 to 3 DIustrate the operation of a menu control function In the system of Figure 1. 
Figure 1 shows a don>estic video entertainment system comprising a satellite broadcast tuner 10, a video 
cassette recorder (VCR) 1 2 and a television receiver 1 4, all connected to a serial data bus 1 6. Video and audio 

50 signals are passed within and between the devices 10,12,14 using, for example. SCART (Euroconnector) 

plugs, sockets and multiwire cables. 

The serial data bus Is in this embodiment a Domestic Digital Bus (D2B) as standardised by the International 
Elertrotechnlcal Commission (lEC). Geneva. D2B provides for distributed control of the bus. and allows com- 
mands and other messages to be uniquely addressed for specific "devices", such as the apparatuses 10,12 
55 and 14. and also for specific "subdevices* within each device. 

Within each device 10.12.14 there are shown blocks representing D2B subdevices. The division of a device 
into subdevices is necessary only in a logical sense, that is to say, from the point cf view of its behaviour relative 
to the serial bus 16. In the physical implementation of the device, there may or may not be corresponding sep- 
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arate physical subdevices. In the embodiment shown, each device includes one audio/video controller (AVC) 
type of subdevice plus others which are logically separate and logically connected to the bus as indicated by 
the dotted data paths in Figure 1 . Ihe AVC subdevices provide the (distributed) controlling logic of the system 
as a whole, interpreting user commands and controlling the operation of the system accordingly. In the physical 

5 Implementation of the device, the control logic of the AVC and some or all of the other subdevices will often 
be integrated using a single programnwd microcontroller. Other subdevices not shown in Rgure 1 will generally 
be included in such a system, including timers, audio amplifiers, and so forth, and the subdevices described 
herein are presented as a representative sample only. 

In the satellite tuner device 10. a tuner subdevice 26 (TUN) performs the signal processing functions nec. 

10 essary to provide baseband video signals to the connected apparatuses. The AVC subdevice 20 receives user 
instructions from a user input/output (User I/O) subdevice 27 (UIO) (the front panel and/or remote control of 
the satellite tuner) and D2B messages from the bus 16. and operates to select channels, keep track of preset 

channel selections and so forth. 

The VCR device 12 includes its AVC subdevice 22. and also a User I/O subdevice 29 (UIO). a terrestrial 
15 broadcast tuner subdevice 28 (TUN), a switchbox subdevice 30 (SB) and a videotape recordyreplay deck 32 

(DCK). , 

The television receiver device 14 includes its AVC subdevice 24 and also a user input/output subdevice 
41 (UIO). a terrestrial tuner subdevice 42 (TUN), a switchbox subdevice 44 (SB) and a video monitor subdevice 
46 (VID)! The User 1/0 subdevice 41 of the television receiver includes an on-screen display (OSD) function. 
20 as described hereinafter, and a remote control 41a for the receipt of user control signals. 

In operation, the tuner subdevices 26.28 and 42 can be regarded as sources of video signals with in the 
system. The video monitor subdevice 46 can act as a destination for video signals, and functions to display 
images to the user. The record/replay deck subdevice 32 can act as a source and/or a destination of video 
signals, depending whether It is playing and/or recording at a given time. 

25 Since the functional elemente within the apparatuses 10,12,14 are addressable as D2B subdevices. any 
of the AVC subdevices 20.22.24 can take control of the bus and address conmands to those subdevices. This 
is done for example by an AVC subdevice which has been informed of a user command by a User I/O subdevice 
and requires control of subdevices at various points in the system to implement the user's wishes. 

D2B message formats for controlling the basic functions of certain common subdevices are defined al- 
so ready in the lEC standard referred to above, whBe scope is left for defining not only new commands, but also 
request and reply messages that enable one D2B device or subdevice to interrogate another as to its properties 
and status. Each switchbox subdevice 30 and 44 can be controlled via the bus (or by its associated AVC sub- 
device) to connect its output data paths(s) a specified one of its input data paths. For example, if a user indi- 
cates to the television receiver device 14 that it is desired to watch a certain sateflite broadcast channel, suitably 

35 addressed and coded D2B messages can be sent via the bus 16 to ensure that the satellite tuner 10. VCR 12 
and the television 14 are active, to cause the satellite tuner 1 0 to select the appropriate channel, to cause the 
VCR switchbox subdevice 30 and the television switchbox subdevice 44 to connect the appropriate signal path 
from source to destination. There are many ways of arranging these events with or without user interventton. 
For greatest user-friendliness, the whole process can be controlled by the AVC subdevice of the device which 

40 receives the user Input The Informatton necessary for buDdIng the signal path from source to destination can 
be obtained by a suitable series of D2B request messages to the relevant devices and subdevices. A suitable 
system for providing such control Is described In GB-2 223 114.A1 (PHN12678). In that system no AVC eub- 
device requires knowledge of the complete system, only Its nearest nelghboure. 

In order to provide a user-friendly user Interface for the system, any AVC subdevice (hereinafter 'AVC^ 

45 may wish to display user messages using the on-screen display (OSD) facility of the User I/O subdevice 41. 
For example, when the television is activated by a user and a signal path set up according to the user's wishes, 
the AVC 24 may wish to confirm visually for the user which channel Is being watched. If the signal comes from 
the satellite tuner 10, a conventbnal on-screen display would be able to confirm no more than the fact that 
the signal Is coming from an external connec^r of the television 14. To allow the displayed Information to In- 

50 dude the actual channel name, known only within AVC 20, a device Information process Is set up. with the 
AVC 24 acting as the Initiating AVC and AVC 20 acting as an addressed AVC. This process Is described In 
detail In copending European patent appllcatton EP-0 505 006-A2 (PHQ91010). 

The device Information process provides only a one-way flow of Information, however. Auser-friendly op- 
eraUon could be enhanced by the abfllty for the VCR 12 and satellite tuner 10 to display menus for the user 

55 i^ing the OSD function of the User I/O subdevice 41 of the television 14. and to receive the user's menu se- 
lections back from the User I/O subdevice to control further operation. To this end. menu control functions are 
now defined in the AVC subdevices 20 and 22. and in the User I/O subdevice 41 of the television. The menu 
control functions are standardised for reliable operation, but aDowing as nrujch freedom as possible for the man- 



4 



EP 0 535 749 A2 



ufacturers of the different apparatuses to provide their own style of implementation. For example, the television 
manufacturer might develop a particular visual style of menu, with use of special text fonts and colour-coding 
of menu entries, for example, whie the VCR nrianufacturer might develop a particularly efficient and intuitively 
operable menu tree structure. Both of these elements can be combined by appropriate partitioning of respon- 

5 sibDities between subdevtces in the menu control function, as described below. 

Figure 2 shows a standardised menu window layout, of the type that can be generated in the embodiment 
described. The menu window 200 is divided Into a header f fled 210. an information field 212 and a selection 
field 214. The header field has roomfora single lineof text 216, of a length W characters, which text is defined 
by a string of W character codes in accordance with a standard character set The information field contains 

10 room for a number HI of lines of W text characters, and can be used by the AVC to give instructions to the 
user. 

The selection field 214 has room for a number H2 of items for user selection. The AVC provides a text string 
of W-4 characters to identify the item to the user. The leftmost four characters are available for the User I/O 
subdevlce to show selection key infbrnnation 218for each item. Thus in the embodiment described, there might 
15 be buttons marked V, 'b', 'c\ 'd' and V on the remote control handset 41a of the television 14, and the User 
I/O subdevice 41 recognises these buttons as selectors of the five displayed menu items. Alternative embodi- 
ments might use other symbols, or colour coding as the selection key information. 

For the purposes of menu control functions, the present embodiment distinguishes between the functions 
of an AVC subdevice and a User I/O subdevice, and defines the n^ans of cooperation between the two sub- 
20 devices. 

With regard to menu control the AVC subdevice has three states: Inactive, Active and Exchanged. In the 
Inactive state, the AVC is currently not engaged in a menu control session. In the Active state, the AVC is cur- 
rently engaged in a menu control sesston on a certain User I/O subdevice or it is trying to establish a menu 
control session with a User I/O subdevice. In the Exchanged state the AVC is engaged in a menu control ses- 

25 sion, but one of the generated menus has given the user the ability to transfer nienu control to another device, 
and the right of menu control has transferred to the AVC subdevice of that device. 

Since it is assumed that an AVC can have only one menu control session active at one time, each AVC is 
only able to start a menu control session if It is in the Inactive state. In the other states the AVC will not start 
a menu control session when requested by a local event or a [menu][onl command, described below. 

30 As far as menu control is concerned, an AVC maintains the following data items: 
State • Inactive, Active, or Exchanged 

Initiating AVC - Device-subdevice address of the AVC subdevice that initiated the menu control session, 

if applicable. This could be the AVC itself in case of e.g. a local event 
Transferred AVC - Device-subdevice address of the AVC subdevice to which menu control has been trans- 
33 ferred, if applicable. 

User I/O • Device^ubdevice address of the User I/O subdevice on which the menu control session 

is running. 

With regard to menu control the User I/O subdevice has three states. Off, On and Transferring. In the Off 
state, no menu Is displayed. In the On state, one menu Is currently displayed or Is about to be displayed. In 
40 the Transferring state, the User I/O subdevice Is transferring menu control from one AVC to another AVC. Since 
It is assumed that an User I/O subdevice can display only one menu at a time, It can only start a menu control 
session If It is In the Off state. If the User I/O subdevice has Its menu control function in the On state, then It 
will not start another menu control aesston. 

As far as menu control Is concerned, an User I/O subdevice maintains the following data: 
45 Current state - On, Off or Transferring. 

Current AVC - Devioe-subdevloe address of the AVC which currently has a menu control ses- 

sion (that Is It may define a menu) with the User 1/0 subdevice. and to which user 
conrvnands regarding menu control will be sent 
Window specification - The User I/O subdevice knows whether a window specification has been re- 
30 ceived or not For the detaQs of the window specification see the description of 

the comnuind [define menu window] below. 
Menu Items - The User I/O knows all menu items which have been defined and their current 

status as far as user Input/control Is concerned. For details of the data for each 
Item see the description of the commands [define menu Item] and [user entry] be- 

55 low. 

The command messages defined to allow Implementation of the menu control function via D2B will now 
be described, to be followed by a brief Dlustration of their use in practical operation. 

A Menu Control connmand [menu contrdllstate] is defined for use by a User I/O subdevice to exchange 
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the right of menu control from one AVC to another AVC. Three different [state] parameters are defined: (givenj. 
which includes the device-subdevice address of an iniUating AVC; [finished], which Includes the address of a 
current AVC; and [atiorted], which includes the address of a current AVC. 

If the [menu controlHgiven] command is received by an AVC which is in the Inactive state, then the ad- 
dressed AVC goes to the Active state, stores the device-subdevice address specified in the command as the 
initiating AVC. stores the device-subdevice address of the User I/O subdevice which sent this command as 
the current User I/O. and starts menu control on that User I/O subdevice. When menu control is finshed (for 
example the AVC/user decides to stop menu control), the addressed AVC returns menu control to the init.atmg 
AVC via the current User I/O subdevice with a [menu 8ession][finished] command, described below. 

If the [menu controOLgwen] command is received by an AVC which is in the Active state or in the Exchanged 
state then the addressed AVC does not start a second menu control session but returns the right of menu 
control to the specified initiating AVC via the current User I/O subdevice with a (menu session]Iaborted] conv 

nrand. described below. ^ . . »u n. -i 

If the [menu controlllf inished] command is received while the AVC is in the Exchanged state, then the ad- 
dressed AVC goes to the Active state, stores the device-subdevice address of the User I/O subdevice that 
sent this command as the current User I/O and resumes menu control on t hat User I/O subdevice. The specified 
current AVC is the AVC which finished its menu control and returned the right of menu control to the AVC which 

received this command. ^ , , j 

If the [menu control][aborted] command is received whfle the AVC is in the Exchanged slate, then the ad- 
dressed AVC goes to the Active state, stores the device-subdevice address of the User I/O subdevice that 
sent this command as the current User I/O and resumes menu control on that User I/O subdevice. The specified 
current AVC indicates the AVC which was asked to start menu control but was not able to do so and therefore 

aborted. ^ , 

A Menu Session command [menu sessionnparameter] is defined for use by an AVC to start or stop a menu 

control session with the OSD function of a User I/O subdevice or to transfer a menu control session to another 

AVC. The parameter field can take the value (offj. [on], (transfer), [finished] or [aborted]. The value [transfer] 

includes the address of a new AVC. \falues [finished] and [aborted] include the address of an initiating AVC. 

If the [menu session][off] command is received whfle the menu control function of the User I/O subdevice 
is in the On state and the devfce-subdevice address of the AVC which sent this command is the same as that 
stored as the current AVC. then the menu control function goes to the Off state. 

If the [menu sessionHon] command is received whfle the menu control function of the User I/O subdevice 
is in the Off state, then the menu control funcUon goes to the On state and the device-subdevice address of 
the AVC which sent this command is stored as the current AVC. The User 1/0 subdevice also memorises that 
a window specification has not yet been received and it dears the list of menu Hems. If the (menu sessionjon] 
command is received whfle the menu control function of the User I/O subdevice is m the On state or Trans- 
ferring state, then the User I/O subdevice disregards this command, since it can store data for only one session 

at a time. ^ . ^• 

If the [menu 8ession][transfer] command is received from the current AVC whfle the menu control function 
of the User I/O subdevice is In the On state, then the User I/O subdevice goes to the Transferring state where 
It transfere menu control from the current AVC to the new AVC subdevice specified in the command, by Issuing 
a command (menu controinglven] to the new AVC. If this command Is transmitted successfully, the menu control 
functton of the User I/O subdevice goes to the On state and replaces the devlce-subdevtee address stored as 
the current AVC with the address of the new AVC. If the command transmission was not successful, the User 
I/O subdevice issues a command [menu control][aborted] to the current AVC and goes to the On stale. It also 
memorises In either case that a window specfflcatlon has notyet been received and cleare Its list of menu Items. 

If the [menu sesslonl[f Inished] command Is received from the current AVC wWIe the menu control function 
of the User I/O subdevice is In the On state, then the User I/O subdevice goes to the Transferring stale where 
it transfers menu control from the current AVC to the specified Initiating AVC. The User I/O subdevice Issues 
a command (menu contron[f Inished] to the specified Initiating AVC. If this command Is transmitted successfully, 
the menu control function of the User I/O subdevice goes to the On state, and replaces the device-subdevice 
address stored as the current AVC with the address of the specified Initiating AVC. It also memorises that a 
window specif icatton has not yet been received and It clears the list of menu Items. If the command transmission 
was not successful, the User I/O menu control function goes to the Off state. 

If the [menu sesslon][aborted] conunand Is receh^ed from the current AVC while the menu control function 
of the User I/O subdevice Is In the On state, then the User I/O subdevice goes to the Transferring state where 
ft returns menu control from the current AVC to the specified InlUatIng AVC. The User I/O subdevice Issues a 
command (menu control]Iaborted] to the specified initiating AVC. If this command is transmitted successfully, 
the menu control function of the User I/O subdevice goes to the On state, and replaces the device-subdevice 
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address stored as the current AVC with the address of the specified initiating AVC, It also memorises that a 
window specification has not yet been received and dears the list of menu items. If the command transmission 
was not successful, the menu control function of the User I/O subdevice goes to the Off state. 

A Menu Entry command [menu entryHoperand] is defined for use by a User I/O subdevice to inform an 

5 AVC subdevice that the user has entered a command to start, stop or restart menu control. The operand can 
take the value [offl.Ion].Irepeat] or [previous]. 

When the user indicates a desire to start menu control, the menu control function of the User I/O subdevice 
will send the command (menu enfryKon] to the AVC subdevice stored. When the user has requested return to 
a previous menu, then the menu control function will send the comniand [menu entryHprevious] to the AVC 

10 subdevice. tf the current menu of the menu control session has been garbled, corrupted or overwritten by the 
User I/O subdevice and the menu has to be re-displayed, then the last displayed menu can be asked for by 
sending a [menu entrylrepeat] conmiand to the current AVC subdevice. When the user indicates a desire to 
end menu control while the menu control function of the User I/O subdevice is in the On state, then the menu 
control function wOl send the conrunand [menu entryloff] to the AVC subdevice stored as the current AVC. 

15 If an AVC subdevice receives the conrunand [menu entry][of f] while it is in the Active or Exchanged state, 
and the AVC device-subdevice address stored as initiating AVC is equal to its own device-subdevice address, 
then the AVC subdevice wiD send a comnrand [menu session][offl to the User I/O subdevice stored and then 
the menu control functbn goes to the Inactive state (i.e. the AVC subdevice stops the generation of menus). 
If an AVC subdevice receives the command [menu entryKoff] while it is in the Active or Exchanged state, and 

20 the AVC devfce-subdevice address stored as initiaUng AVC is not equal to its own device-subdevice address, 
then the AVC subdevice will send a D2B command [menu sessionpnished] to the User I/O subdevice stored 
and then the menu control function goes to the Inactive state (i.e. the AVC subdevice stops the generation of 
nrtenus). 

If the AVC subdevice receives the command [menu entry][onl whOe it is in the Inactive state, then the menu 

25 control function goes to the Active state, stores the device-subdevtee address of the User I/O subdevice which 
sent this command, starts a menu control session with the menu control function of that User I/O subdevice 
and starts menu control at its main menu. 

If an AVC subdevice receives the command [menu entryl [previous] whHe it is in the Active state, then the 
following applies. If the menu control feature is not in the main menu, then it goes to the previous menu (e.g. 

30 it goes up one step In the menu tree). If the menu control feature is in the main menu, and the AVC devfce- 
subdevice address stored as initiating AVC is different from its own device-subdevice address (i.e. the menu 
control feature has been started by an external AVC subdevice via an User I/O subdevice with a [menu con- 
trol][given) command), then the AVC subdevice sends a [menu session][f inished] command to the current User 
I/O subdevice and then goes to the Inactive state. Otherwise it stops the menu control session on the User 

33 I/O subdevice stored with a [menu 8e&sion][ofn command. 

If an AVC subdevice receives the command [menu entryllrepeat] while it is in the Inactive state, then the 
menu control function goes to the Active state, stores the device-subdevice address of the User I/O subdevice 
which sent this command, starts a menu control session with the menu control funcUon of the User I/O sub- 
device and restarts menu control at Its current menu (i.e. the menu last sent), if an AVC subdevice receives 

40 the command [menu entrylrepeat] while It Is In the Active state, then the menu control function redefines Its 
current menu (Le. the menu last sent) to the menu control function of the User I/O subdevtee stored. 

A Define Menu Window command [define menu wlndow][window spedf icatlon] Is defined for use by an 
AVC to propose a menu that may fit In the menu window provided by the menu control function of the User 
I/O subdevice. The parameter [window specification] contains information defining the proposed menu format, 

45 Indudtng: 

- whether the menu Is a main menu era normal menu, that Is whether It Is possible to go higher In the me- 
nu tree' by nrteans of a oonunand [menu entryHprevious]; 

- the width W In characters of the menu header and menu Infornrwtlon fields 210 and 212; 

- the number of lines In the information field 212; 

so - the width In charactere of each Item, allowing space for the key Information 218, to be defined by the 

User t/O subdevice; and 

- a list of Item types, Including as many Item types as there are to be Items In the menu. 

Several different Item types may be defined In addition to the simple selectable Items DIustrated In Figure 
2. For example 'slider' controls for volume, brightness levels etc. can be provided, and lten» which allow entry 
55 of numeric items such as radio frequencies and personal identification codes. When a User I/O subdevice re- 
ceh^es this command, it verifies If It b In the On state and If the device-subdevice address of the stored AVC 
is equal to the device-subdevice address of the AVC which sent this conrunand. and if the required menu spec- 
ification can be displayed In the menu window supported. 
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A Display Menu Header command [display menu header][text string) is defined for use by an AVC (the AVC 
which is known to the User I/O as having the right of menu control) to send text for the menu header field 21C 
to the User I/O subdevice. Simflarly, a Display Menu Text command [display menu textJItext string] is defined 
for uses by the AVC to send text for the Information field 212. 

5 A Display Menu Item command [display menu itemlptem numberpem specification] is defined for the cur- 

rent AVC to send a text f ield and other parameters of the item to the User I/O subdevice. \/Vhere different types 
of menu item are possible, the field frtem specification] should reflect correctly the item type of the item iden- 
tified by the field ptem number], as defined in the list of item types in the previously supplied window specify 
cation. The field [item specif ication] also specifies for example when and how feedback is to be supplied to 

10 the AVC in response to user actions by means of the conrvnand (user enb^] described elsewhere. 

A User Entry command [user entrypem numberHselect state] is defined, for use by a User I/O subdevice 
to return a user entry to the stored AVC. Each [user entry] command defines the updated state (for example: 
selected or de-selected) of the menu item identified by the [item number] operand. As fares the User I/O sub- 
device is concerned, several \iems can be in the selected state at one time, other operands are defined for 

15 the other item types such as sliders and numeric entry itenns. 

Also defined are request messages [menu control?], [menu session?] and [menu window?]. Request [menu 
control?) can be addressed to an AVC to find out the state of its menu control function: Active, Inactive or Ex- 
changed. A reply [Active] will also specify the initiating AVC (which can be the addressed AVC itseiO and the 
current User I/O as known to the addressed AVC. A reply [Exchanged] will also specify the initiating AVC and 

20 the transferred AVC. Request [menu session?] performs a similar function when addressed to a User I/O sub- 
device, which v«il reply [On],[Off] or [Transferring]. The reply [On] wfll specify the current AVC, while the reply 
(Transferring) specifies both the current AVC and the new AVC. The request [menu window?] is used by an 
AVC which has sent a window specificaUon (see Define Menu Window command) to find out if the User I/O 
subdevice can display the specified menu. If the reply is that the User I/O subdevice cannot display the spe- 

25 df ied menu, the reply contains a specification of a window that is possible, in terms of width, number of items 
and so forth. 

The operation of the menu control functions of the system of Figure 1 will now be Olustrated by the exam- 
ples of Figures 2 and 3. 

In the operation of the menu control functions of the system there are basically three alternative events 
30 which can give rise to the start of a menu control session: 

- an AVC starts menu control due to a local event (for example end of tape, user presses a key on the 
local keyboard, or the need for authorizatk>n in case of conditional access); 

- the user wants to start menu control via a User I/O subdevice (for example he/she presses a 'start menu 
control* button on the remote control hand set) and 

33 - an AVC which shows a menu, has as one of the options to transfer menu control to another device (for 
example one of the menus of the television allows menu control to be transferred to the VCR). 
When, due to a local event such as end of tape In the VCR 12, the AVC 22 (for example) wants to stert 
menu control, it simply starts a session with the menu control function of the User I/O subdevice 41 , by sending 
a [menu 6esslon][on] conrunand. The AVC then defines the menu window and Items therein, and receives the 

40 user's menu selections from the User I/O subdevice. When the menu control has finished, the AVC 22 releases 
the menu control session In the User I/O subdevice 41 with a [menu sessionKoff] command. This might happen 
due to the user ending menu control (whteh Is then Indicated to the AVC v^rtth a [menu entrynoff] command) 
or due to a local event (for example no user response on the current menu for a certain period of time, or the 
user puts the device In standby using local keys). 

45 It may be In the couree of menu control operattons that one of the Items selected on the menu generated 
by the AVC 22 of the VCR 12 relates for example to the recording of a programnw from the satellite tune 1 0. 
This may Involve channel selection In the satellite tuner, and also operations for obtaining conditional access 
authorisation (pay^as-you-vlew television). Clearly, for a consistent menu-based user Interact ton. It Is desirable 
that such operations can be performed by the user with a view of the system as an Integrated whole, without 

50 concern as to whether this menu or that affects one apparatus or another (or all of them). At the same time, 
it Is Impracticable to expect the AVC 22 (for example) to know the menus and actions required to control all 
apparatuses In the system, particularly In view of the fact thatthese apparatuses can bo added to the system 
at any time, and may come from different manufacturere. 

Figure 3 llustrates how the facility to transfer menu control from one AVC to another and back again can 

55 be used to provide an Integrated menu control function for a group of apparatuses In such circumstances. Time 
is represented vertically down the drawing, with actions of a User I/O subdevice (41 , for example) represented 
in a central column, and actions of a first AVC (for example AVC 22 of the VCR 12) and a second AVC (for 
example AVC 20) represented to the left and right respectively. The device-subdevice addresses of these sub- 
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devices are represented as UIO. AVC1 and AVC2 respectively. Arrovw represent bus requests and commands, 
whose names are abbreviated in the drawing, for reasons of space. A solid vertical line indicates menu control 
state Active or On in the corresponding subdevica. , ». 

At the start of the sequence of Figure 3. the first AVC (AVC1) has Inactive for its menu control state. At 
300 command [menu sessionUon] is addressed to the User I/O subdevice. and at 302 a request [menu ses- 
sion'?! is sent to the User I/O subdevice. The rejAy to this request at 304 indicates that a menu control session 
has been stated successfully between subdevices UIO and AVC1 . The subdevice AVC1 proceeds at 306 supply 
a menu window specification, define menu header text, information text and item texts using the commands 
described above. The subdevice UIO then displays these on the television screen and begins to supply [user 
entry] commands in response to the user's selection of items from the displayed menu. 

In the course of these operations, an item is selected which requires transfer of menu control to subdevice 
AVC2 The subdevice AVC1 responds tothe corresponding [user entry]command by addressing a [menu con- 
trol?] request to the second AVC subdevice AVC2. Subdevice AVC2 replies at 312 that its menu control state 
B Inactive The first AVC sends command [menu session][transfer AVC2] to the subdevice UIO at 314. and 
enters the Exchanged state. The User I/O subdevice UIO at 316 uses command [menu control][given: AVCI] 
to inform the second AVC that the transfer is desired. 

Assuming a successful transfer, the second AVC enters the Active state and at 318 initiates menu display 
and control with the User I/O subdevice. At 320, the subdevice UIO informs the second AVC that the user 
(having finished or aborted menu control of the corresponding apparatus) has requested a return to the pre- 
vious menu. Since the previous menu was generated by an 'initiating AVC which is not the second AVC itself 
the second AVC concludes its menu control operaUons at 322 with a command [menu session][rm.shed: AVCI] 

to the subdevice UIO, entering the Inactive state. . . . 

At 324 the Subdevice UIO uses command [menu control] [finished: AVC2] to inform the first AVC that menu 
control responsibility is returned to it The first AVC then resumes its menu display at 326 and at 328 receives 
a [user entry] command v»*hich indicates the end of menu control operations. The first AVC therefore terminates 
the menu session with subdevice UIO by sending [menu sessionl[off] at 330. 

Of course an infinite range of eventualities are possible in a real system, which can be handled in a con- 
sistent manner thanks to the predefined meaning of the bus commands and requeste defined above. Menu 
control can be transferred repeatedly dowm a chain of three or more AVCs. yet with control always being re- 
turned correctly to the initiating AVC. At the same lime, each subdevice need only maintain a finite and pre- 
defined set of date within appropriate to its current state, enabling a low-cost implementation. Adding the facility 
to store a second set of such data would allow an AVC to take part in two menu control sessions, so that for 
example the 'chain' of AVCs just mentioned would be able to 'double back' to the same AVC. 

From reading the present disclosure, other modifications will be apparent to persons skilled in the art Such 
modtfications may involve other features which are already known in the design, manufacture and use of loral 
communication systems, domestic audtoA/Weo apparatuses and component parte thereof and which may be 
used instead of or in addition to features already described herein. For example, there are possible forms of 
user dialogue other than menu control. Also there are many possible forms of rerial data channel other than 
D2B The date channels may. for example, be provided via copper wire, optical fibre or wrtreless links. 

Although claims have been formulated In this appltoatton to particular combinations of features. It should 
be understood that the scope of the disclosure of the present appllcatton also Includes any novel feature or 
any novel comblnatton of features disclosed herein either explicitly or ImpBcitly or any generalisation thereof, 
whether or not It relates to the same Invention as presently claimed In any daim and whether or not It mitigates 
any or all of the same technteal problems as does the present invention. The applicanlB hereby give notice 
that new claims may be formulated to such features and/or oomblnattons of such features during the prose- 
cution of the present appllcatton or of any further appltoatton derived therefrom. 



Claims 



A local communication system comprising first and second apparatuses connected for the exchange of 
messages to a serial data channel, the system Including control means within thef Iret apparatus and user 
Interface means within the second apparatus, said control means Including: 

means (a) for Initiating a user dialogue session v/lth the second apparatus; means (b) for during 
said user dialogue session sending to the second apparatus at least one user Information Item for pre- 
sentetton to a user of the system; means (c) for during said user dialogue session recehrtng from t he sec- 
ond apparatus informaUon which conveys user control signals by reference to said user information 
item(s): and means (d) for controlling at least part of the system in accordance with user's vnshes inferred 
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20 



25 



from the said information, 

said user interface means including: 

means {e)for during said user dialogue session receiving fromthe first apparatus user information 
time and presenting them to the user means (f) for during the user dialogue session receiving a control 

5 signal from the user; means (g) for identifying an association between the user control signal and one of 

said user information items; and means (h) for sending to the first apparatus Information which conveys 
the received user control signals by reference to the associated user information item, 
wherein the system further Includes a third apparatus including further control means, said further control 
means induding means corresponding at least to means (b), (c) and (d) above, wherein the control means 

10 within the f iret apparatus further includes nrwans (j) for during the user dialogue session initiating a trans- 

fer of control of said session to the third apparatus, and wherein said further control means within the 
third apparatus further indudes means (k) for receiving transferred control of the user dialogue session, 
such that the means corresponding to means (b), (c) and (d) will continue the transferred session without 
active partidpation by the control means within the first apparatus. 

2. A system as daimed in Qaim 1 wherein the user information items indude items in a menu for control of 
the first apparatus, and wherein the means (g) Indudes means for identifying an association between a 
user control signal and a specific one of said menu Items. 

3. Asystem as daimed In aaim 1 or2 whereinthemeans(a)ofthefirstapparatusindudesmeansforstoring 
data identifying the second apparatus for the duration of the user dialogue session and wherein the sec- 
ond apparatus indudes means forstoring data identifying the apparatus with which it currently has a user 
dialogue session. 

4. A system as daimed in Claim 3 wherein the second apparatus acts as intermediary between the first and 
third apparatuses in the transfer of the user dialogue session. 

5. A system as daimed In Oalm 3 or 4 wherein the means (k) of the third apparatus Includes means forstoring 
data Identifying the first and second apparatuses during the continuation of the user dialogue session 
by the third apparatus. 

6. A system as daimed in Qaim 3. 4 or 5 yet further Induding a fourth apparatus wherein the control means 
of the third apparatus further indudes means corresponding to nrteans 0) for initiating a further transfer 
of the user dialogue session to the fourth apparatus. 

35 7. A system as daimed in Claim 3, 4, 5 or 6 wherein the control means of the third apparatus further Indudes 
means (m) for initiating the return of the user dialogue session to the first apparatus. 

8. A system as daimed in any preceding dalm wherein the or each control noeans and the user Interface 
means are individually addressable via the serial data channel as a control subdevice and user Interface 

40 subdevice respectively, the stored data Identifying each such means comprising its subdevice address, 

9. An apparatus comprising a control means and an interface to a serial data channel, the apparatus having 
the technical features of the first apparatus of a system as daimed in any of Qaims 1 to 8, 

10. An apparatus comprising a control means and an Interface to a serial data channel, the apparatus having 
^ the technical features of the first and third apparatuses of a system as daimed in any of Claims 3 to 7. 

11 . An apparatus comprising user output means, user Interface means and an Interface to a serial data chan- 
nel, the apparatus having the technical features of the second apparatus of a system as daimed in any 
of Claims 1 to 6. 

12. An apparatus as daimed in Qaim 11 further comprising control means, the apparatus further having the 
technical features of the first and. as the case may be, third apparatus of the system. 
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